Im not against changing the code block color but not this way. If we want a new one we should create a new color theme with --wp-code-{100,200,300}.

Keep in mind its used in various other places as well.

I don't think we need a full palette for a single light/dark code highlighting color.

I agree the naming is not optimal and doesn't fit into the current schema. Open for suggestions.

We dont need a full pallete right now we only have 100 and 200 just change the color of these.

100 and 200 are usually shades of bigger palette with 100 being the lightest value. We don't have a "real" palette for wp-code. Yes, two values exist

  --wp-code-100: theme('colors.int-wp-secondary.300');
  --wp-code-200: theme('colors.int-wp-secondary.600');

and yes, these again refer to another palette, but these values are also somewhat arbitrary and IMO not matching well in the UI. Hence I don't think that mimicking a palette is the best way forward here.

There should only be one color for wp-code ever IMO, for both light and dark. How about consolidating the two existing ones to one definition named wp-code? The two existing ones are only used in one instance in the code, respectively.

We are getting lost in discussions again. At the end, I don't really care, and wp-code works for me as well.

Hm, I think this was just a normal discussion? You brought up some reasons, I replied and shared my thoughts. It is not even about subjective UI but code syntax, so I'd say such discussions are normal (and needed and good).

Sorry this was not meant to be offensive or rude :) The color is only used in one location. While I have some personal preferences, I don't care much enough to discuss further how it is done in detail. wp-code works for me we can still change it later on if there is any need for a color palette. Sorry if my last message was misleading.

Consolidated all mixed wp-code definitions into wp-code-bg now, which aligns with the logic of wp-code-text.

@xoxys Is this acceptable in your view? Yes, the color is custom and not derived from the main colour palettes but I don't think that any value from these matches well here.

Need to run the PR image first to see in which places the changes trigger a change.

Fine for me.

OK, my recent changes also change the bg color of the main log container. More work needed.

Ah yeah, I remember. That's why it's a bit questionable whether we really want to change the color, but I'm still fine if we want to change it only for real code blocks.

@xoxys You can take another look. I think I was able to keep all previous colors while achieving a much more consistent palette - tailwind mapping that should ease future UI changes.

Uhm the overall look and feel is still completely different and I dont like it:

On this view, the hover/non-hover color is inverted compared to the one in the screenshot above. Non-hover is white hover, is gray. This is IMO the correct behavior but should be used everywhere. The borders are way too dark now.

Uhm the overall look and feel is still completely different and I dont like it:

I am actually confused why it looks like this now. The last time I checked it looked completely different.
Not sure, why maybe I did too many PRs in parallel.
Just to state explicitly, that this is not the look I indented.